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THE CHALLENGES OF DISTRIBUTED SYSTEMS 


With the rapid improvement in micro processor technology and 
its consequent dramatic reduction in costs, one thing seems clear: . 
small computers will soon penetrate business in a big way. The day 
of the ‘work station processor’ is not far off. In some cases, these 
small computers will be part of multi-level systems designed and 
installed by the central data processing staffs. In other cases, they 
will be small, stand-alone computers that will, however, have the 
capability to communicate with the corporate data center. In either 
case, these “distributed systems’ pose challenges not only to the data 
processing function but also to user management and staff. Here 
are some steps to take to help mitigate the problems. 


EF ord Motor Company, headquartered in 
Dearborn, Michigan and with almost one-half 
million employees world-wide, has been using 
computer technology since almost the first days 
of the computer. In addition, the various divi- 
sions within the North American operations have 
had a good deal of autonomy in designing the 
systems and in selecting the equipment they use. 


It is not surprising, then, to find that units — 


within Ford have explored in some depth the ap- 
plication of just about every new advance in 
computer technology. That has been the case, for 
instance, in the emerging new area of ‘distrib- 
uted systems.’ 


Some time ago, Mayford Roark, Executive 
Director of Ford’s Systems Office, addressed a 
group of European data processing executives. 
His talk dealt with Ford’s early experiences with 
_ distributed systems; he recently updated the in- 
formation for us. Roark stressed an overriding 
| philosophy: with distributed systems, as with 


other advances in computer technology, the ques- 
tion addressed was “how best can we organize 
available computer resources to accomplish a | 
particular mission?” He then singled out four il- 
lustrative experiences within Ford. 

The first case, said Roark; concerned the order 
processing system within the Ford division, 
which connected 35 district sales offices in North 
America to division headquarters. In 1968, a de- 
centralized system was in use, with IBM 360/ 
20s installed at each office. But the decentralized 
system was not meeting management’s needs. 
Management wanted the ability to query the 
sales order files for details that were not availa- 
ble in the general office’s file. Further, the dis- 
trict office installations had to be staffed around 
the clock, for doing the processing and for com- 
municating with headquarters; costs were thus 
higher than desired and were growing. 

In this instance, said Roark, the division con- 
cluded that a centralized system would be a bet- — 
ter solution. So, in 1972, the application was 
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converted to a centralized system, with remote 
batch terminals located in each district office. 
Not only could management now query all sales 
order files but it was also possible to reduce the 
overall operation to two shifts and with fewer 
operators, he said. 

But the system structure for this application 
has not stopped there. The Ford division is now 
in the process of installing new mini computers 
that will handle working files at each district 
office, to provide vehicle order status and sales 
data. The master records will still be stored at 
the general office. The working files, updated 
daily from the master files, will be used locally 
on an interactive basis, for scheduling orders and 
for analyzing sales trends. 

In the second example, at about the same time 
that the Ford division put in the centralized sys- 
tem, the automotive assembly division saw a 
need to restructure its material control applica- 
tion, for 20 assembly plants in North America. 
This division also considered a centralized sys- 
tem but rejected it, the main reason being that 
the greatest reporting needs were at the plants, 
not at the general office. In addition, the division 
had found that if the people at the various plants 
looked upon the data files as ‘our’ files, the in- 
tegrity of the data improved. 

So, in this second case, the division chose to lo- 
cate the master stock status files at the plants 
and to maintain only a summary file at the gen- 
eral office. The plants would send only those 
data items needed by the general office, on a 
daily basis. In addition, the computers at the 
plants were used for many other applications of 
a strictly local nature. 

For his third instance, Roark cited the experi- 
ence of the Ford parts division that sells about 
200,000 service parts from 20 depots throughout 
North America. The accounting functions for 
this division were centralized in Dearborn 
around 1961 and a centralized real-time inven- 
tory control system was installed in 1968. 

In 1973, however, this division developed a 
dealer order entry system, designed to give spare 
parts availability information to dealers on a fast 
response basis. For this system, inventory files at 
the depots were more economical than putting 
the central inventory file on a fast response basis. 
So the system that was installed includes a mas- 
ter parts file at Dearborn and depot inventory 
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files at each depot. The depot files are loaded 
daily from the central file. In structure, the sys- 
tem is quite similar to that of the automotive as- 
sembly division, except that the flow of data be- 
tween the master files and subsidiary files is re- 
versed. 

The fourth example concerned Ford’s electri- 
cal and electronics division. This division has 
been a leader in the use of mini computers for 
industrial control applications, said Roark. In 
addition to their control functions, the minis are 
being used to provide data input for such appli- 
cations as attendance reporting, time reporting, 
production testing, and quality audits. This data 
flows to a central computer at each plant, which 
in turn updates the files and processes queries. 

In short, said Roark, the various divisions 
within Ford are making use of a variety of sys- 
tem structures, including both centralized and 
distributed. Further, the divisions have ‘gone in 
both directions’—that is, from decentralized to 
centralized, and from centralized to distributed. 
Each system has been designed to put the com- 
puter resources where they would do the most 
good for accomplishing a particular mission. 


Bank of America 


The Bank of America, with headquarters in 
San Francisco, California, is the world’s largest 
bank, measured in terms of assets (over $80 bil- 
lion). The banks’s main operations are in Cali- 
fornia, where it has some 1,092 branches and 
two data processing centers—in San Francisco 
and Los Angeles. 

The bank has operations at many other places, 
however, such as in seven major cities of the U.S. 
and in 101 countries outside of the U.S. In fact, 
Bank of America processes data electronically at 
about 70 sites. 

Two characteristics of Bank of America’s op- 
erations—the huge volume of activity within 
California plus the large number of processing 
centers outside of California—have led to two in- 
teresting projects in distributed systems. One of 
these might be called ‘ciustered mini computers’ 
and the other ‘data collection and reporting.’ 


Clusters of mini computers. Drake, in Refer- 
ence 1b and at the conference of which this ref- 
erence is the proceedings, pointed out the reasons 
behind the idea of clusters of mini computers. 


No single computer, regardless of size and speed, 
can cope with the bank’s large volume of trans- 
actions in California, he said. Thus, the bank 
operates many large scale computing systems to 
provide the needed batch throughput to handle 
the high volume of daily posting activities. 


But there are three main shortcomings of these 
batch systems that led the bank to evaluate on- 
line account inquiry systems. One shortcoming is 
the high cost of producing the printed daily 
status of customer accounts. Another is the slow 
process of tellers looking up customer status in- 
formation or phoning another branch for that in- 
formation. And the third reason is the exposure 
to fraud that the batch printouts provide. 


An on-line system would have its share of 
difficulties, though. About 8500 on-line terminals 
would be required throughout the branches. In 
order to handle inquiries fast enough to keep 
customer lines in branches at reasonable levels, a 
response rate of sixty inquiries per second is re- 
quired. No existing central DBMS is fast enough 
to provide that response with a database of 12.5 
million loan and deposit accounts. So the solu- 
tion chosen was a distributed system. 


The bank has selected an approach to distrib- 
uted processing that uses low cost modules of 
mini computers. ‘The customer loan and deposit 
account records are assigned to modules. Each 
branch of the bank communicates with the mod- 
ule that has its data. 


For its modular processing capability, the 
bank has designed a reliable ‘processing module’ 
consisting of four mini computers—two for mes- 
sage handling and routing and two for local data 
base management and application processing. 
Each of these pairs of minis is loaded to only 
50% of its capacity, so that if one mini goes out, 
the other mini can carry the load. 

By way of the software, a module is special- 
ized to handle one type of application or a small 
number of very similar applications. The goal 
here was to keep the programs simple and the 
processing fast. 

Communication standards have been set up 
for communicating between modules. 

Currently, five of these modules have been in- 
stalled in San Francisco, for serving branches in 
Northern California, and five have been installed 
in Los Angeles for serving Southern California. 
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These clusters of mini computers meet the re- 
quirement for high reliability and high transac- 
tion rate for this transaction oriented on-line sys- 
tem. However, they do not provide for other re- 
porting requirements. The reporting system re- 
mains a batch type operation, with its volumi- 
nous output and slow process of program devel- 
opment and maintenance. 


Data collection and reporting. With the many 
processors worldwide, the bank’s management 
has been faced with the problem: how to provide 
the concurrent consolidation of data from more 
than one processing center and from more than 
one application? While the various processors 
are essentially free standing, management needs 
a means to both get meaningful consolidated re- 
ports from the processors and to be able to probe 
downward for detailed data as required. 


The elements of the bank’s proposed solution 
to this problem is as follows. Local database 
processing, at the local machine level, must pro- 
vide access to data in a manner appropriate to 
the primary use of the equipment. The access 
method may be relatively simple in nature, such 
as indexed sequential, or more complex, with 
numerous access paths and data relationships. 
Next comes a global datamanager, a hardware and 
software combination that logically integrates the 
part of the network for which it is responsible. 
This global datamanager will contain a global 
directory of data and a global query language 
processor. It will serve one or more processing 
sites. The greater the capability of the local data- 
base processor, the more functions the global dat- 
amanager will delegate to it. Finally, a user inter- 


face will provide a natural language capability 


and will translate human queries into the global 
query language. 

In operation, says Drake, a user will enter a 
query for information via the user interface facil- 
ity. The query will be translated into the global 
query language and sent to the nearest global 
datamanager. This global datamanager, in turn, 
will consult its global data directory and will di- 
rect a series of messages to other global data- 
managers throughout the network, asking for the 
desired data. The latter global datamanagers will 
direct the retrieval of the desired data (for those 
local systems employing only rudimentary access 
methods) or will turn the retrieval tasks over to 


the local DBMS. It will then send the requested 
data back to the originating global datamanager 
for delivery to the user. 

One of the main potential cost items in moving 
to a distributed system is the need to totally re- 
vise existing application programs. The bank is 
seeking to avoid this cost—by way of the global 
datamanagers. The global datamanagers allow 
communication with existing application sys- 
tems, ranging from simple transaction systems to 
complex query systems. They also enhance se- 
curity because all data flows between sites must 
go through them and hence be subject to control 


General Electric Company 


Slone (Reference 1a) has described one ap- 
proach that his company has tried, in the use of 
distributed processing. 

When manufacturing companies have used a 
combination of maxi and mini computers in the 
past, said Slone, there tended to be not much in- 
teraction between them. Then gradually, data 
began to flow between them, perhaps by way of 
magnetic tape. Today, the maxis and minis are 
still largely dedicated to their own tasks, and the 
links between them remain quite casual. 

Further, he says, the minis of the past have 
not been very convenient for application system 
development. The available software has been 
quite limited, forcing users to develop very applhi- 
cation-dependent software (and, to make matters 
worse, often in assembly languages). So the ap- 
plication development costs for the minis have 
been relatively high, in his opinion. 

What is needed for effective distributed 
processing, he says, is a way of using both the 
maxis and the minis in a hierarchical structure 
and in a manner the gives the benefits and 
strengths of each. To accomplish this, he says the 
following elements are needed: (a) high level 
programming languages to be used for an on-line 
environment; (b) effective data base management 
for both the maxis and minis; (c) data base in- 
tegrity and recovery facilities for a multi-access 
environment; (d) integrated transaction process- 
ing software; and (e) easy-to-use links to the 
maxi computers. 

To demonstrate the feasibility of this ap- 
proach, his department has developed a general- 
ized software system (that they call MADTRAN) 
to run on a hierarchy consisting of a Honeywell 


EDP ANALYZER, AUGUST, 1978 


H6080 as the maxi and DEC DECsystem-10s as 
the minis. A pilot application system, involving 
job time data handling, has been installed on the 
system. 


The minis are essentially free-standing sys- 
tems that perform transaction processing and the 
updating of their local data bases. (They can also 
be used for real-time control of factory equip- 
ment, but this feature was not included in the pi- 
lot system.) 


In the pilot application that has been imple- 
mented, job data is transmitted from the maxi to 
the appropriate minis. This data includes stan- 
dard production times for the jobs. During the 
day, actual job data is entered on the minis, 
showing actual production accomplished and 
hours expended. At the end of a shift, the mini 
produces performance reports for the factory 
foremen. Also, records pertaining to completed 
jobs are stripped from the local file and sent to 
the maxi, where labor distribution, payroll, 
planning reports, and so on, are produced. 


To ease the task of creating application soft- 
ware, Slone’s group has developed an ‘edit and 
prompt’ package. The developer(s) of an appli- 
cation system need only supply descriptions of 
message formats, editing rules, and prompts for 
missing fields. The package generates edited, 
fixed format messages for the application pro- 
grams. 


Another point of interest is that, by means of 
an input code, the terminal operator can indicate 
whether he/she wants to be prompted for each 
input field (for novices) or whether a prompt can 
call for multiple fields. 


Further, the mini may have to call on the 
maxi for processing or data that is not available 
at the mini. The transaction code itself might de- 
termine that such service is needed, or the termi- 
nal operator may signal that connection to the 
maxi is desired. 


We checked to see about more recent informa- 
tion on this system, but no further information is 
being released at this time. 


The push for distributed systems 


In the instances discussed above, the pressure 
to install distributed systems came from two 
main sources. In some of the cases, the initiative 


came from the central data processing manage- 
ment and staff, because they could see the prob- 
lems of trying to handle a growing workload on 
large, central computers. In other instances, the 
initiative came from user department manage- 
ment who sought some benefits that they felt 
centralized data processing could not offer or of- 
fer as economically. 


We suspect, from the comments that we have 
heard on this subject, that most frequently the 
push to install a distributed system comes from 
user department management, the end _ users. 
The main reasons seem to be (1) dissatisfaction 
with centralized data processing and (2) seeking 
benefits not easily available from centralized data 
processing. 


Dissatisfactions. An Infotech report (Refer- 
ence 2) has caught many of the complaints that 
end users have voiced about centralized data 
processing. 


Very briefly, these usually hinge upon the be- 
lief that centralized data processing is a near mo- 
nopoly with a captive audience. Centralized data 
processing is motivated by things other than user 
happiness, say the critics. Data processing has its 
own set of priorities as to which jobs to run 
when time schedules get tight. Also, user man- 
agement may have little or no control over their 
data processing expenditures, and they do not 
know how much they are really getting for their 
money. 


Another complaint is that, with centralized 
data processing, the risk of loss is greater than it 
would be with distributed processing. Fires, 
floods, or disgruntled programmers may destroy 
the data files and programs. When the central 
system goes down, all on-line users cease work. 
Yes, there are practices that can be followed to 
help mitigate such problems, but those practices 
may not always be followed. The risk does exist. 


Seeking benefits. Typically, the end users pre- 
fer to be responsible for their own activities— 
that is, to run their own system, under their own 
sets of priorities, subject to their own budget, and 
using their ‘own’ data files. End users typically 
feel, we believe, that they can more easily obtain 
these benefits with their own computers than 
they can from sharing a central system. 


Another type of benefit comes from the fact 
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that most of today’s mini and micro systems pro- 
vide interactive operation with immediate access 
to files. Not only does this provide faster turn- 
around but it also tends to catch errors of input 
right on the spot. 

A possible benefit of distributed systems is that 
of cost reduction. We will have more to say 
about this point below. 


A variety of approaches 


While it is commonly recognized, we believe, 
that the term ‘distributed system’ 1s ambiguous, 
it is worth reviewing briefly some of the different 
meanings given to the term. 

Distributed data entry is a function to which the 
name ‘distributed system’ is frequently given. 
Key-to-tape, key-to-disk, key-to-diskette, and 
key-to-cassette data entry devices are often mar- 
keted under this term. 

Distributed processing, central data storage in- 
volves the use of intelligent terminals at the re- 
mote points, connected through a network to a 
central processor and data files. Hierarchical dis- 
tributed systems often have this structure. 

Distributed processing, local data storage implies 
that the local sites have both processing and data 
file storage capabilities. To make them part of a 
distributed system, they should have some means 
of co-operating with each other, perhaps by com- 
municating over a data communications network. 
This form of distributed systems implies the con- 
cept of a distributed data base. While the true dis- 
tributed data base is probably beyond today’s 
state of the art, it 1s receiving much attention. 
We will say more about this work later in the 
report. 

Small, stand-alone systems are being marketed 
today under the name of distributed systems. 
Under this approach, each department might 
have its own mini or micro computer based sys- 
tem—but there is no assurance that the various 
departmental computers will be able to commu- 
nicate with each other or with a headquarters 
computer. 

As we will point out later, it seems to be in 
this area of the small, stand-alone departmental 
computer that most of the concern about distrib- 
uted systems is concentrated. 

Work station systems are in the offing, as we 
discussed two months ago. They will act as per- 
sonal terminals and will replace the typewriter, 


the hand calculator, and so on. They probably 
will be marketed as distributed systems. 


As yet, slow progress 


Even with this variety of approaches, sup- 
ported by today’s technology, one must concede 
that the acceptance of distributed systems to date 
has been quite slow. Perhaps distributed data 
entry is the variety that has received the most ac- 
ceptance, but even here the growth has been 
steady rather than dramatic, we gather. 


We have observed that a strong, central data 
processing staff tends to resist the pressure for 
putting processing power and (particularly) data 
storage at the locations of the end users. Instead, 
these staffs appear to argue for the following ap- 
proach, which has been reasonably successful. 


First, centralize data processing, say these 
people. A lot of organizations still have numer- 
ous, perhaps somewhat small data processing in- 
stallations—a holdover from the ‘1401 days.’ A 
good amount of program and data incompatibil- 
ity still exists. So the best step to take in such in- 
stances, say these centralists, is to first get things 
under control. Remove the incompatibilities by 
putting all applications on a central system. This 
will make a future conversion to a distributed 
system much easier. 


Second, off-load some data entry functions in 
order to distribute this workload and to reduce 
errors of input. If the people who understand the 
data are the ones who perform data entry, data 
integrity will improve. This off-loading may be 
accomplished either via an on-line system (such 
as a time sharing system) or via key-to-disk or 
other such devices. But the processing programs 
and data files remain at the central site. 


Third, install intelligent terminals (which 
might replace the data entry terminals) that have 
local data storage capability. The main data files 
would still be centrally maintained, but local 
sub-files would be used for local processing and 
handling inquiries. Also, the programming of 
these terminals might be controlled centrally, 
perhaps by not providing a local programming 
capability (as with the IBM 3790 terminals). 


Two points stand out in this approach. One, 
the organization may still be in the process of 
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cleaning up the ‘mess’ resulting from the prolif- 
eration of computer usage in the 1960s. Sec- 
ondly, an almost total rework of existing applica- 
tion systems may be needed—whether centraliz- 
ing or distributing. Data processing management 
can often make a strong point against moving to 
distributed systems on the basis of such points. 


Gathering speed 


Maybe progress to date has been slow, but we 
expect that interest in distributed systems will 
accelerate rapidly in the next year or two. 

We see four main reasons for this likely 
speed-up. One is the rapid growth in the micro 
computer technology. Another is the emergence 
of the public packet data networks. The third is 
the economics that seem to be favoring distrib- 
uted systems. And the fourth is an aggressive 
new attitude toward the development of stan- 
dards that will support distributed systems. 


Micro computer technology. We _ discussed 
what is happening in micro computer technology 
two months ago and so will treat the subject only 
briefly here. Much more powerful hardware and 
software are becoming available under this tech- 
nology. ‘The micro processors are now competing 
with the mini computers and soon will be com- 
peting with regular CPUs. Software development 
may well proceed almost as fast. Since micros 
may not be shared among jobs but instead may 
be dedicated to functions or jobs, the software 
may be less complex. 

What this means for distributed systems, we 
believe, is the following. User department man- 
agement will be able to say, “There is no need to 
revise existing application programs. Just let us 
extract the data we need from the existing cen- 
tral files and store it locally, where we will have 
immediate access to it. With our own system, we 
will also be able to handle local jobs that central 
data processing does not want.” 

This will be one strong argument for distrib- 
uted systems, we think. 


Public packet networks. This subject also was 
discussed in depth, last month, so we will treat it 
briefly. 

Public packet switched networks are becoming 
available in many countries, for serving many 
cities and towns in those countries. Further, they 
are providing interfaces for the most popular 


types of computers and terminals. These net- 
works are providing quite efficient data commu- 
nications, at a relatively low cost, particularly for 
low volume usage. 

As far as distributed systems are concerned, 
this means that departmental computers can 
more easily communicate with each other and 
with central data processing. The argument 
against distributed systems “because our network 
won't support them” is becoming less and less 


valid. 


Economics of distributed systems 


One of the main arguments for centralized 
systems has been that of ‘economy of scale.’ But 
that argument is being attacked from several 
sides. 

Reynolds (Reference 6) points out that large, 
centralized installations are losing ground eco- 
nomically in three ways—operating staff costs, 
development staff costs, and hardware costs. It is 
true in a batch environment, he says, that cen- 
tralization has had economic benefits. But with 
the greater use of on-line systems, operator costs 
are becoming less significant. Also, in large 
shops, specialized, rigid operator functions tend 
to develop; in small shops, one person normally 
does many functions. 

As far as development staff costs are con- 
cerned, says Reynolds, the expected savings from 
‘common applications’ that are centrally devel- 
oped often are a mirage. Accounting systems, run 
in a batch environment, can and do show savings 
from centralized development. But this has not 
proved to be so true of engineering and manufac- 
turing applications, which seem to vary from fac- 
tory to factory. In fact, batch systems do not 
serve these applications particulary well. 

Economies of scale in hardware have just 
about disappeared, says Reynolds. He presents 
some comparative figures from studies that his 
staff has made. These figures show that some 
mini computers provide the same _ processing 
power as leading maxi computers (such as the 
IBM 370/155) but at a fraction of the cost. And 
some micros are showing even greater perform- 
ance-cost ratios. 

Reynolds goes on to discuss a number of other 
non-economic factors that seem to be favoring 
the dispersion of computing power and data stor- 
age. 
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Louis M. Branscomb is chief scientist and vice 
president of IBM. Three months ago, he was the 
keynote speaker at a conference of which Refer- 
ence {tc is the proceedings (but the speech is not 
in the proceedings). In his talk, he reviewed 
some studies, by IBM and others, of what is 
happening to data processing and data communi- 
cations costs. In 1975, said Branscomb, one study 
showed that the average DP budget was: commu- 
nications hardware and services, 19%; computer 
hardware and purchased software, 46%; staff sal- 
aries, 35%. Further, studies indicated that the 
communications costs are falling at an average 
rate of 11% a year, computer hardware costs are 
coming down at about 15% a year, and staff costs 
are rising at about 6% a year. If one extrapolates 
the 1975 figures out to 1983 using these trends, 
he said, one finds that communications costs will 
be down to only 10% of the total, computer 
hardware will be down to 17%, and staff costs 
will be up to 73%. 


There is another factor to consider—the 
steady growth in total data processing expendi- 
tures. This growth averages between 12% and 
15% per year. In 1975, the total U.S. expendi- 
tures were estimated at $26 billion. By 1983, an 
estimated $75 billion per year will be spent. 


How will this $75 billion be spent? If the 
above-mentioned 1983 percentage estimates 
(10%, 17%, and 73%) are used, on the assump- 
tion that the 1983 environment would be like the 
1975 environment, that would mean some $55 
billion for staff alone (73% of $75 billion). But 
this extrapolation is not valid, said Branscomb. 
Staff costs will be heid down by transferring 
more of the load to computers and communica- 
tions. In other words, distributed systems will be 
used to hold down staff costs. His company 
thinks the percentages for 1983 will be more like 
39% for communications, 37% for computers, 
and 24% for staff. 


So it is just possible that distributed systems 
will installed as a means for controlling the 
growth of DP staff costs. 


Standards developments 


We cite just three examples of some interest- 
ing work going on in the standards area. In each 
instance, something new has been injected into 
standards work—a real sense of urgency. 


West Coast Computer Faire 1978. We dis- 
cussed the 1978 Computer Faire two months 
ago, as an illustration of the interest in personal 
computers. But there was also some noteworthy 
standards work reported there. 


One of the technical sessions we attended, par- 
tially covered in Reference 3, dealt with hard- 
ware and software standards. The hardware 
standards discussion dealt with the S-100 bus, 
originally developed by Intel and becoming al- 
most an industry standard. In theory, any micro 
processor or peripheral unit that is S-100 compat- 
ible can be just ‘plugged into’ an S-100 machine. 
However, the original timing protocols were de- 
ficient to the point where, as one speaker said, 
“S$-100 compatibility means that the connector has 
100 pins.” The end users were complaining that 
the units they were buying would not work as 
advertised. And the computer stores were upset 
because their customers were upset. 


An IEEE Computer Society committee has 
been working on an S-100 standard; committee 
members reported on the work. The session was 
essentially a proposed 
standard—and members of the audience partici- 
pated in the discussion. Committee members felt 


discussion of the 


that the new ‘standard’ bus would turn out to be 
much better than any individual computer man- 
ufacturer now offers. 


We asked about when the results of this work 
might be of benefit to end users. Possibly as soon 
as later this year, we were told. No, the standard 
might not be officially adopted by the IEEE by 
that time. But as soon as the standard is crystal- 
lized, many of the micro processor and _ periph- 
eral manufacturers probably will start using it, 
because they also are tired of the complaints 
about non-compaitibility. 


(We have heard some experts comment that 
the S-100 basically is not a good design and is re- 
ally not suitable for standardization. However, it 
is very widely used, good design or not, and is 
apparently becoming an ad hoc standard.) 


University of California at San Diego. As we 
discussed two months ago, UCSD has been a 
leader in the use of both micro computers and 
the PASCAL programming language for teaching 
computer science courses. Moreover, they have 
developed a relatively portable software system 
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which allows both application programs and sys- 
tem software to be moved from one type of micro 
(or mini) computer to another. Their software is 
being adopted by a number of micro computer 
suppliers, possibly to supplant BASIC as the main 
programming language for the micros. 

PASCAL has many of the data naming advan- 
tages of COBOL plus the control structures de- 
sired for structured programming. Also, it is 
suitable for interactive program development. 

Kenneth Bowles, at UCSD, has recognized 
that PASCAL has some shortcomings that must be 
corrected before it can have widespread use. In 
an attempt to prevent each supplier ‘doing his 
own thing’ in making such enhancements (as has 
happened with BASIC), Bowles decided to take 
some action. 

He organized a two-week working conference 
that was held last month at UCSD. All inter- 
ested PASCAL suppliers were invited to attend. 
The first week was spent identifying the needed 
enhancements and coming to a tentative agree- 
ment on them. Then the attendees went home 
for a week, to talk over these ideas with their 
colleagues. They then reassembled for the second 
week of the conference, to make any revisions in 
their earlier ideas and to develop more detailed 
specifications for the enhancements. 

It is possible that a relatively ‘standard’ PAS- 
CAL will emerge from this effort and that it will 
gradually become the most widely used program- 
ming language for the micros. 

Bowles also argues that users should start de- 
manding ‘manufacturer independent’ and ‘ma- 
chine independent’ software for micro computers. 
“Don’t get locked into one machine family or 
one manufacturer,” he says. Toward this end, 
Bowles and his associates at UCSD have devel- 
oped a PASCAL pseudo-machine interpreter. The 
PASCAL source code is first compiled into PASCAL 
object code. The interpreter then makes the host 
machine look like a PASCAL machine. The object 
code runs about five times slower than native 
code and the interpreter takes about 8K of mem- 
ory. But if the operating system and other system 
software are also written in PASCAL, then every- 
thing—application programs, system software, 
etc.—can be moved to a different micro just by 
rewriting the interpreter. In fact, they have done 
just that at UCSD. For more information on this 
work, see Reference 7. 


Study Group on Distributed Systems. Last 
month, we briefly mentioned the work of the 
Study Group on Distributed Systems, under the 
American National Standards Institute commit- 
tee on systems planning and requirements. The 
work of this study group, we believe, will add 
momentum to the acceptance of distributed sys- 
tems. 

As we understand it, the charter of this study 
group is to look at the area of distributed sys- 
tems, create a logical structure for the area, see 
where standards are needed, see where standards 
are currently being developed, and then recom- 
mend an organization (and reorganization) of the 
standards work. Further, the study group is ex- 
pected to move as rapidly as possible; distributed 
systems are emerging so fast that the normal 
(slow) standards process is not acceptable. 

The chairman of the study group is Charles 
W. Bachman of Honeywell Information Systems. 
Other companies represented on the study group 
include IBM, Burroughs, Digital Equipment, 
Control Data, Univac, Bell System, and Xerox. 
The U.S. government has several representatives, 
and three other organizations are represented. 

The study group has developed a logical struc- 
ture for distributed systems, as requested. The 
group sees these systems as consisting of net- 
works of co-operating work stations. A work sta- 
tion is a cluster of activities created to do some 
portion of the work of an enterprise. The work 
stations co-operate by exchanging information. 
The study group has been defining several levels 
of protocols to allow this co-operation among 
work stations. Some of these protocols may be 
the subject of international standards efforts. And 
some of these standards might begin to appear in 
the next two years or so. 

For more information on the work of this 
study group, see Reference 4. 

We view these four areas—micro computer 
technology, public packet networks, cost trends, 
and aggressive standards efforts—as supporting a 
distributed system capability. 

Yes, the conditions seem right for much faster 
acceptance of distributed systems. 

But there are some very real problems—prob- 
lems that could turn ‘distributed systems’ into 
‘distributed messes.’ Let us take a look at those 
potential problems and what might be done to 
mitigate them. 
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THE CHALLENGES 


We cannot remember any major technical ad- 
vance in the computer field that has been 
adopted by users without “pain and suffering’ at 
the outset. 

There is good reason to expect, then, that dis- 
tributed systems will cause their share of pain 
and suffering. Let us take a look at where the 
problems probably will lie. 

We will concentrate on the situation where 
user department management wants to install a 
departmental mini or micro computer system, in 
order to perform the department’s own work. 
This is the situation that is encouraged by the 
developments just discussed. 


Management concerns 


As we indicated earlier in this report, strong 
data processing executives have, in many cases, 
resisted the installation of mini and micro sys- 
tems in end user departments. In the face of 
strong pressures from user department manage- 
ment, they have been able to convince executive 
management on the validity of their concerns. 
Here are some of the concerns that we have 
heard discussed. 


Costs. A departmental mini or micro computer 
installation might start out as a small expendi- 
ture, but costs can then gradually get out of con- 
trol. he application programs turn out to cost 


- much more than the hardware. Maintenance and 


enhancement costs turn out to be much higher 
than expected. Computer staff costs, for pro- 
gramming and operations, begin to appear where 
none were really expected by user department 
management. The times and costs for developing 
new applications turn out to be greater than 
budgeted. 

All of these things have been pervasive in the 
past. Why not expect them to happen with dis- 
tributed systems? True, with relatively inexpen- 
sive micro systems, it will be feasible to divide 
big applications into small sub-systems. By re- 
ducing the complexity, some of the problems of 
the past may be avoided. But it would be unreal- 
istic to expect that none of these cost problems 
will occur with distributed systems. 


Quality. The low cost of the hardware may 
lead user department management to expect low 


cost software. Why should one have to pay two, 
five, or even ten times as much for the software 
as one pays for the hardware? This line of 
thinking can (and does) lead user department 
management to select the lowest fixed price bid 
for the development of the application software. 
Since the requirements are essentially never 
stated completely and accurately, this leads to 
troubles. 

What are the ‘troubles’? Again, they are the 
well-known difficulties that most installations 
have experienced. The development project be- 
gins to slip behind schedule and over cost. Cor- 
ners are cut. Programs are quickly (and poorly) 
designed. Documentation is sacrificed. Every- 
thing is done in a ‘quick and dirty’ fashion in or- 
der to stay within the tight budget. Little or no 
use is made of corporate standards, with a loss of 
compatibility between the departmental system 
and the corporate system, in terms of programs 
and data. As multiple departments take this 
same approach, there results a wide variety of 
computer types, operating system types, data 
storage media types, programming languages, 
and so on. 


Reliability. When a departmental mini or mi- 
cro system is brought in, department manage- 
ment has one or a few main applications in mind 
for it. All attention is directed at getting that or 
those applications running. 

But there are other things in addition to the 
application programs that must be considered, if 
the departmental computer is to operate reliably. 
These include the need for backup facilities, re- 
start and recovery facilities, data security, keep- 
ing redundant data files in synchronism, and so 
on. We suspect that, typically, no budget will be 
provided for these things if the departments are 
left to their own devices. 

Just because the departmental computers are 
small is no reason to believe that such needs can 
be ignored. 


Availability of data. As indicated earlier in 
this report, executive management is coming to 
expect the ability to probe downward into data 
files. If some cost figure is substantially higher 
than expected, for instance, management prob- 
ably will want to be able to find out specifically 
what items have caused the excessive cost. 

If each department has essentially gone its 
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own way on installing a computer system, there 
is no assurance that top management will be able 
to probe the departmental files. These files will 
thus be unavailable to higher levels of manage- 
ment. 

These, then, are the main concerns that we 
have heard expressed, from a management 
standpoint, about distributed systems. As some 
people have said, distributed systems (of the free- 
standing departmental system variety) represent 
“the 1401 days all over again.” | 

But, in addition to the managerial concerns, 
there are some technical concerns to be consid- 
ered. 


Technical concerns 


Yes, the technology in support of distributed 
systems 1s progressing very rapidly. Yes, the de- 
signers of the micro processors can design in all 
of the features they would like to see in those 
processors. Yes, work is going on in standards 
that will help provide compatibility for all of the 
components of distributed systems. But No, all of 
the elements of a distributed system have not 
been completed yet. 

Let us take a brief look at some of the as-yet 
missing elements. 


Standards. Standards for distributed systems 
not only have to be developed, agreed upon, and 
adopted, they also must be implemented. And 
there lies a big problem. How well will they be 
implemented ? 

Consider, for instance, the EIA RS-232 signal 
connector interface standard, used for connecting 
terminals to modems, etc. We have talked to peo- 
ple who have tried to connect units from several 
different manufacturers. Often as not, they say, 
something doesn’t match. As the number of dif- 
ferent suppliers increases, the more differences 
that come to light. To some, this interface stan- 
dard “only assures that the connectors will mate, 
not that the electrical signals will match up 
properly.” 

If such a problem exists with something ap- 
parently as standardized as the RS-232 interface, 
think what lies ahead as more complex standards 
are adopted for distributed systems. 


Evolving micros. ‘The very rapid change in 
micro computer technology is well known. Be- 
cause this rate of change is expected to continue, 
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the question arises: how can a company keep 
from getting locked in to ‘old’ micro technology? 

For instance, on the hardware side, the 8-bit 
word length micros are common today. The 16- 
bit micros are beginning to appear (DEC LSI-11 
and Intel 8086). In two years, it has been pre- 
dicted that 32-bit word length micros will ap- 
pear. (There is some controversy on the need for 
such word lengths in micros; they often will be 
used in dedicated fashion, not multi-program- 
med, and will thus not need the huge memories 
implied by 32-bit word lengths.) Also, periph- 
erals are continually improving in performance 
and lowered costs. 

Much the same situation prevails in software. 
Today, BASIC is the most common higher level 
language for the micros, but it has a lot of short- 
comings. PASCAL may replace it as the common 
language for the micros. Improvements are being 
made in operating systems, DBMS, communica- 
tion monitors, etc. for the micros. 

So the micros that are installed in the next one 
or two years might well become technically obso- 
lete fairly quickly. How can distributed systems 
be designed so that they can evolve with the tech- 
nology, and not get held back by old hardware 
and software? This is a challenge—and Bowles 
solution, mentioned above, is one approach to 
meeting that challenge. 

And then there is the question of distributed 
data bases. 


Distributed data bases 


This brief discussion draws on Liebowitz and 
Carson (Reference 1d), the work of the 
CODASYL Systems Committee (Reference 5a) 
and Bachman’s commentary on this CODASYL 
report (Reference 5b). Readers interested in this 
subject should see these references. 

The CODASYL Systems Committee has studied 
and described the new environment where multi- 
ple data bases reside at the nodes of a distributed 
system. Their report has been published in the 
hope that others will study it and comment on it. 

Bachman, in his commentary, points out that 
essentially all of today’s systems are really dis- 
tributed ones. There are essentially no truly cen- 
tralized systems, where just one computer and 
one data base serve the needs of the whole com- 
pany (certainly true for larger size companies). 
There are almost always multiple computers and 
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multiple data bases. So distributed systems, as 
the term is now being used, really involve con- 
necting those components that are already dis- 
tributed. 

The CODASYL report sees a distributed data 
base node as consisting of (a) a network access 
process for interfacing the node with the commu- 
nications facility, (b) a network DBMS function 
that includes the more conventional DBMS func- 
tion, (c) a local data base, and (d) user processes. 
The committee has presented design alternatives 
for structuring such systems, as well as technical 
and administrative issues related to their use. 

The committee is asking: “Is this the way 
these systems are likely to look? Can you suggest 
more likely alternatives? If we can agree on the 
likely structure, this will help guide develop- 
ment.” 

Bachman adds that a mechanism is needed 
that (a) allows messages to flow between the 
nodes of the system (between the co-operating 
work stations), (b) provides restart and recovery 
facilities, as well as concurrency control, and (c) 
has a means for reaching agreement that a job 
has been completed correctly. 

Liebowitz and Carson address the question of 
finding data in a distributed data base system. 
Each node can have its own directory, which can 
be for local data only or for the complete system 
(highly redundant). There can be a central direc- 
tory, which can be the only directory or which 
acts in concert with local directories. And there 
might be regional directories. With redundant 
directories, the main problems are storage costs, 
duplicate updating, and keeping the directories 
in synchronism. If redundant directories are not 
used, the network will be cluttered with “I need 
record X, do you have it?” messages. 

Perhaps this brief description has pointed out 
some of the technical challenges associated with 
distributed systems. 


Distributed systems: what to do? 


The challenges and the problems of distrib- 
uted systems are real. So how can an organiza- 
tion go about coping with this new technology? 

The answer depends on which approach to 
distributed systems is taken. 


Centrally designed hierarchical system. As far 
as we can tell, the ‘successful’ distributed systems 
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that have been installed to date have been de- 
signed and implemented by the central data 
processing staff. This is the approach that IBM, 
for one, seems to be currently advocating. 

The only advice we have come across for this 
approach is almost ‘old hat.’ It is much the same 
as we presented three months ago in connection 
with DBMS conversions. ‘The same advice applies 
for using any new, complex technology for the 
first time. Take it easy for the first application of 
a distributed system. Pick a non-trivial but also a 
non-vital application for the first efforts. Have 
realistic expectations; a distributed syste will 
be more difficult to install and will cost more 
than the first estimates generally indicate. Treat 
the distributed system project like any other sys- 
tem project, using good project management 
methods. And start immediately to take steps to 
make future conversions to new technology eas- 
ler. 


Free-standing department systems. ‘This is per- 
haps the most challenging situation of all for 
data processing management because it is so 
hard to control. The end users, in this case, are 
trying to break their dependence on central data 
processing and might well resist any effort by the 
central staff to help them. 

Nevertheless, we suspect that most end users 
will need such help. Here is what we see as 
needed. 

Consulting and training. Earlier in this report, 
we discussed a number of management concerns 
about distributed systems—involving costs, qual- 
ity, reliability, and availability of data. These are 
the areas where the user departments need help. 
Central data processing might develop guidelines 
of good practices, for use by other departments 
for installing their own computers. And_ short 
training courses might also be in order, to be 
given to department representatives. 

Get running on time sharing. This is an excellent 
approach that user departments might be en- 
couraged to take. If the company has an appro- 
priate in-house time sharing network, perhaps it 
can be used. If not, consider using a commercial 
time sharing service to get the application(s) de- 
veloped and running. Then, when running satis- 
factorily, bring the job in-house on a departmen- 
tal computer. There is a better chance with this 


EDP ANALYZER, AUGUST, 1978 


approach that corporate standards can be fol- 
lowed when developing the application systems. 
Also, a much better hardware and system soft- 
ware selection might be made under this ap- 
proach, as opposed to making the selection before 
the application is developed. 


The pressures for distributed systems will be 
too powerful to resist, we believe. But the chal- 
lenges posed by these systems must be overcome, 
or a real ‘mess’ is sure to result. 
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